| Back to Nov 95 How-To Columns | Up to Table of Contents | Ahead to Nov 95 Windows Online |
BY: Martin Heller
MOVING TO A NEW house is right up there on my list of experiences to avoid--slightly below flaying, but above root canal. Moving falls below flaying because it's nonfatal in most cases, but the stress level seems comparable. I learned a lot about myself and my family when the pressure was high.
We survived our move--all but one of the cats, who followed the children out of the house, went down the street with her tail in the air and never came back. We put posters all over the new neighborhood, we called, we went back to the old house--nothing. We don't know if she's dead, off in the woods or in somebody's house. It's amazing how attached you can get to a plain gray cat you rescued from the shelter and raised from a kitten.
It's amazing how attached you can get to a lot of things. Take programming the Windows API in C. Please.
When I was developing my database application in Clarion for Windows for a hospice (see my August column), I constantly ran into situations where I thought, "I know how to write this in C using the Windows API. Let me try it that way. It must be the same." Of course, it never was. It was much simpler, once I found the right Clarion visual tool or built-in function. When I started working with Clarion I was constantly painting myself into corners. After I got past the learning curve and stopped trying to turn Clarion into the Windows SDK, things went much more smoothly.
I've had the same sort of experience developing MFC (Microsoft Foundation Class) programs. The whole idea of MFC was that you could build on your knowledge of the Windows API. Yet MFC has grown to the point where knowledge of the Windows API doesn't get you very far. If you move from programming Windows in C with the SDK to programming in C++ with MFC, you'll probably experience an intensely frustrating learning period. You may become even more frustrated when you try to debug your MFC program.
Using MFC to write Wintune 95--WINDOWS Magazine's next-generation benchmark and system tune-up tool--seemed like a good idea at the time.
(At press time, Wintune 95 was still in development.) Our experience--Dave Methvin's, Eldon Ziegler's and mine--has been interesting. We got off to a quick start bringing up the user interface. Then we had trouble figuring out how to use C++ templates with MFC collection classes. Once we got there we had more trouble figuring out how to make DLLs written in MFC work with an EXE written in MFC. We also had trouble getting everything to share MFC30.DLL so we don't need multiple copies of the classes floating around in memory. We got there, too. Nothing was difficult--just poorly documented and intensely frustrating.
Then we started to run into weird and unusual Windows NT/Windows 95 incompatibilities in the MFC libraries. For instance, we added a splitter window, which worked fine on Windows NT, but crashed a late beta of Windows 95 utterly and completely. This is not what we bargained for when we adopted the compiler and application framework of the company that produces the operating system.
Last month, I reported problems using the Visual Basic 4.0 beta on the new Windows NT shell. I think I understand now.
The preferred way to open files in any current version of Windows is to call the file open common dialog using GetOpenFileName, which takes an OPENFILENAME structure. One of this structure's fields contains flags. You get the new Explorer-style file open dialog in Windows 95 by including the OFN_EXPLORER bit in the Flags parameter.
Applications wise in the ways of Windows NT and Windows 95 set only the OFN_EXPLORER flag when they detect they're running on Version 4.0 or higher (using GetVersion or GetVersionEx). That test breaks down on the new NT shell because the new shell reports itself as Version 4.0 and doesn't quite support Explorer-style file opens. This looks to me like a minor synchronization problem that should be fixed.
I was planning to explain the relationship between OLE (object linking and embedding) and COM (component object model) this month. OLE relies on COM for its plumbing. COM, in turn, relies on the IUnknown interface, which I thought was part of OLE--it's certainly part of the OLE implementation.
I thought I had this down cold until I realized all the explanations I could find about this stuff were self-referential. Consider this sentence from one of Kraig Brockschmidt's articles: "All components based on COM are called component objects because they support fundamental notions of reusability, encapsulation and polymorphism." That helps me a whole lot. Sheesh.
Before all you COM and OLE gurus write in and tell me I'm missing the point, let me say this: I've begun to understand this stuff at some practical level. And for my sins I've slogged through all 977 pages of Brockschmidt's book Inside OLE 2 (Microsoft Press; also available on the MSDN CD), not to mention Nigel Thompson's two series of MSDN articles, OLE for Idiots and The Component Object Model. I know that COM objects need to implement AddRef, Query Interface, and Release methods in their IUnknown classes, and that these interfaces are the key to making the components work. I can even implement the stuff--if I use MFC and rely heavily on the wizards.
My experience with MFC hasn't been uniformly warm and fuzzy. And once I get beyond what the wizards can do, I'm faced with using a bunch of obscure MFC/OLE macros or confronted with the whole clanking mechanism of RPCs (remote procedure calls), marshaling stubs and IDL (interface description language). Neither fills me with joy.
Why is this stuff still so hard? It seems the PC revolution has been about transferring control of computers from the glass-room priesthood to users, and moving programming from the MIS departments with three-year lead times to those who understand the applications. How can you expect those who understand applications to deal with all the gibberish surrounding COM and OLE?
We have a new priesthood: the Order of OLE. Its motto: Abandon all hope, ye who enter here.
So maybe I won't try to explain OLE and COM. Maybe I'll teach you something simple, like how to write a word processor.
That wasn't a joke: The RichEdit control included in Windows 95 and in Windows NT 3.51, sometimes referred to in the literature as the RTF edit control, implements the guts of a word processor. The RichEdit control supports a large subset of the Rich Text Format standard, meaning it allows characters to be formatted, lines to be aligned and so on. It also can hold a large amount of text. You can see the RichEdit control at work in WordPad, the word processing applet that replaces Write in Windows 95.
In Create a RichEdit Control, I show you how you can create it, edit it, size it, enable file drag-and-drop, load a file into it and save a file from it. Most of the communication with the RichEdit control is done with messages.
In Create a RichEdit Control, the calls to InitCommonControls and LoadLibrary take care of initializing the necessary DLLs. The CreateWindowEx call creates the RICHEDIT control, DragAcceptFiles tells the system the control window can handle drag-and-drop messages, and the EM_SETEVENTMASK message with ENM_DROPFILES tells the control window you want it to process drag-and-drop messages.
The MoveWindow call in response to WM_SIZE takes care of sizing the RichEdit control to your main window's client area. If you have a toolbar or status bar, you'll have to do a little more work here. The WM_DESTROY message handling is primarily cleanup.
The code under the WM_NOTIFY message case takes care of loading files dropped onto the control. OpenThe-File initiates an "edit stream read" on the control, in conjunction with EditStreamCallback. SaveTheFile initiates an "edit stream write" on the control, in conjunction with SaveCallback.
I'll leave the remainder of the code required to turn this into a full-blown word processor on the order of WordPad as an exercise for the student. If you'd like a head start on your homework, try consulting Nancy Cluts' book Programming the Windows 95 User Interface (Microsoft Press; also available on the MSDN CD). I derived much of the rather Spartan example in this column from Nancy's code.
It's time to sign off--I hear the siren song of boxes waiting to be unpacked.
Martin Heller consults on and writes about Windows programming from Andover, Mass. If you see his cat--or have some feedback on his column, you can Click Here to find his e-mail ID.
BY: Martin Heller
include <windows.h>
include <commctrl.h>
include <richedit.h>
include <string.h>
InitCommonControls();
HANDLE hRichEdit = LoadLibrary("RICHED32.DLL");
//...
switch (message) {
case WM_CREATE:
HWND hWndRTF = CreateWindowEx(WS_EX_CLIENTEDGE,
"RICHEDIT", "", WS_CHILD | WS_VISIBLE | ES_MULTILINE
| ES_SAVESEL | WS_HSCROLL | WS_VSCROLL, 0, 0, 0, 0,
hWnd,(HMENU)ID_RICHED, hInst, NULL);
DragAcceptFiles(hWndRTF, TRUE);
SendMessage(hWndRTF, EM_SETEVENTMASK, 0,
(LPARAM)ENM_DROPFILES);
break;
case WM_SIZE:
MoveWindow(hRichEdit, 0, 0,
LOWORD(lParam), HIWORD(lParam), TRUE );
break;
case WM_DESTROY:
if (hWndRTF)
DestroyWindow(hWndRTF);
if (hRichEdit) {
FreeLibrary(hRichEdit);
hRichEdit = NULL;}
PostQuitMessage(0);
break;
case WM_NOTIFY:
if (((LPNMHDR) lParam)->code == EN_DROPFILES) {
char lpszFile[80];
HANDLE hDrop = ((ENDROPFILES *) lParam)->hDrop;
WORD cFiles = DragQueryFile(hDrop, 0xFFFF,
(LPSTR) NULL, 0);
if (cFiles > 1)
return 0;
DragQueryFile(hDrop, 0, lpszFile,
sizeof(lpszFile));
if (strstr(lpszFile, "TXT"))
OpenTheFile(hWndRTF, SF_TEXT, lpszFile);
else if (strstr(lpszFile, "RTF"))
OpenTheFile(hWndRTF, SF_RTF, lpszFile);
DragFinish(hDrop);
return 1; }
return 0L;
break;
}
//...
BOOL OpenTheFile( HWND hWndRTF, int iAttrib,
char *lpszFileName) {
HFILE hFile;
OFSTRUCT of;
EDITSTREAM eStream;
if (hFile = OpenFile(lpszFileName, &of, OF_READ)){
eStream.dwCookie = hFile;
eStream.pfnCallback = EditStreamCallback;
eStream.dwError = 0;
SendMessage(hWndRTF, EM_STREAMIN, (WPARAM)iAttrib,
(LPARAM)&eStream);
CloseHandle((HANDLE)hFile);
return TRUE;
}
return FALSE;
}
DWORD CALLBACK EditStreamCallback(DWORD dwCookie,
LPBYTE pbBuff, LONG cb, LONG FAR *pcb) {
ReadFile((HANDLE)dwCookie, pbBuff, cb, pcb, NULL);
if (*pcb < cb )
return 0; // all done
else
return ((DWORD)*pcb); // there's more
}
BOOL SaveTheFile( HWND hWndRTF, int iAttrib,
char *lpszFileName ) {
HFILE hFile;
OFSTRUCT of;
EDITSTREAM eStream;
if (hFile = OpenFile(lpszFileName, &of, OF_CREATE)) {
eStream.dwCookie = hFile;
eStream.dwError = 0;
eStream.pfnCallback = SaveCallback;
SendMessage(hWndRTF, EM_STREAMOUT, (WPARAM)iAttrib,
(LPARAM)&eStream);
CloseHandle((HANDLE)hFile);
return TRUE;}
return FALSE;
}
DWORD CALLBACK SaveCallback(DWORD dwCookie,
LPBYTE pbBuff, LONG cb, LONG FAR *pcb) {
WriteFile((HANDLE)dwCookie, pbBuff, cb, pcb, NULL );
return 0;
}
BY: Eric Carr
Click Here to see a
40.3KB bitmap image of artwork
which goes with this article, entitled:
It's Not Too Late
Click Here to see a
69.2KB bitmap image of artwork
which goes with this article, entitled:
Pick a Protocol
Click Here to see a
9.37KB bitmap image of artwork
which goes with this article, entitled:
Do We Connect?
Click Here to see a
25KB bitmap image of artwork
which goes with this article, entitled:
Were You Given the SLP?
THERE I WAS, getting a little R&R on Block Island off the Rhode Island coast, when a strange feeling came over me.
I realized it was separation anxiety; I couldn't bear the thought of spending a weekend without my laptop. Feeling faint, I rushed up to my room. Much to my relief, there it was, beckoning me from the balcony. Phew! Now all I had to do was gain access to my office resources 3,000 miles away on the West Coast.
Fortunately, Windows 95, combined with my Dell laptop's modem, gives me at least four ways to connect to and use the information in my office--even when I'm not there. Your office may not have as many connection options as mine does, but one of these methods should suit your needs and fit into your corporate environment.
I'm talking about solutions that come "in the box" with Win95. Some of these solutions are available only on Win95's CD-ROM version. If you plan to use Serial Line Internet Protocol (SLIP), you'll need the Win95 CD, or at least the CD's image loaded on a server. There are other connectivity options as well, such as the remote-access servers from J&L and Cubix, or the do-it-yourself solutions with computers, modems and a copy of an application such as pcAnywhere.
What do you need to connect? The hardware list is short and simple, but essential. First, you'll need a modem (and cable, of course) that's compatible with Win95 and your computer. This shouldn't be a problem; I counted well over 90 modem manufacturers (representing several hundred models) in Control Panel's modem setup applet. You'll also need several megabytes of free disk space, but that's all you'll need. The included software handles the balance of the remote connectivity equation.
Once you have everything, you're ready to start making decisions about how to get connected. The first decision: What are you going to connect to?
Win95 includes connectivity tools for many kinds of remote access servers, as shown in the first column of the "Pick a Protocol" table. You communicate remotely with these servers at the most basic levels via wide area network (WAN) communication protocols. Don't confuse these with LAN protocols; WAN protocols control data transmission over a WAN. In this case, the WAN is the telephone network between you and your office. LAN protocols control data transmission over the LAN on which the remote access server resides. What you're running back home dictates which WAN protocol you should use, in terms of both the remote access server and the LAN protocols it lets you use to communicate with other resources on the network.
The four WAN protocols included with Win95 are Point-to-Point Protocol (PPP), NetWare Connect, Microsoft Remote Access Service (RAS) and SLIP. You can use each with specific remote access servers and LAN protocols running on these servers. Which is best? Wrong question. A better question is: Which is best for you?
The table indicates PPP is the most flexible WAN protocol supplied with Win95. But if you're running NetWare Connect or have an extensive Unix setup back at the office, there's no reason you shouldn't use either of those protocols. The one limitation is that your Win95 machine can act as a client (as in the ability to dial out) only when using the SLIP or NetWare Connect protocols. When running PPP or RAS, the Win95 machine can perform as a dial-out client or a dial-in host. For most road warriors, dial-out is sufficient.
One more caveat: Before you start to configure your connections, you'll need to run a protected-mode client. You can't use real-mode clients with the Dial-Up adapter. So for now, you have to use the Client for NetWare Networks or the Client for Microsoft Networks. The good news is that any network protocols you previously defined (for a local network attachment) are automatically bound to the Dial-Up adapter.
If you didn't install the Dial-Up Networking component when you installed Win95, you can do so quickly by selecting the Add/Remove applet in Control Panel and clicking on the Windows Setup tab. In Components, click on Communications and select the Details button, as shown in It's Not Too Late. To install the components for Dial-Up Networking, click on the Dial-Up Networking item, then click on OK. Make sure you click on OK in the Add/Remove Programs Properties dialog box. You'll have to restart Win95; once you do, Dial-Up Networking appears as a System folder in My Computer. Open the folder and double-click on the Make New Connection icon, or use the Connections/Make New Connection menu to invoke the Make New Connection Wizard. (See Do We Connect?)
Now, just follow the screens as they lead you through the steps to configure the connection. A quick tip: When you key in the phone number, insert a comma before the extension. This ensures you've attached to an intermediary host (like a PBX). Before you know it, you're ready to click the Finish button on the wizard's dialog box. Go ahead, but you're not quite done yet.
Once the wizard has finished, you'll see your newly defined connection listed in the System folder. Before you start connecting, verify what you'll be dialing into. Right-click on the icon to get the connection's properties and click on the Server Type button. The default entry, PPP: Windows 95, Windows NT 3.5, Internet, will appear. This does you no good if you need a connection to a NetWare Connect or Windows for Workgroups server. So it's best to check and, if necessary, select the correct server protocol type. If you can't find SLIP server support, don't worry--you haven't messed up. Take a look at Were You Given the SLIP?
After you've selected the right dial-up server protocol, you'll note the option Log On To Network is enabled. Win95 does this by default, and then attempts to attach you to the dial-up server by using the user name and password you entered when you started up Win95.
You have other choices in this dialog box. If you enable software compression, you'll reduce the amount of data sent between your client and the server, but this only works with the PPP protocol. If you're using NetWare Connect, SLIP or RAS, you can't use software compression. Also, an encrypted password camouflages the password as it's transmitted between client and server. Both devices can understand what was sent, but a third party that might be listening in wouldn't know what the actual password was.
Finally, one last detail: enabling and configuring your TCP/IP settings. If you know the IP addresses of various resources on your dial-up network, enable TCP/IP, click on the TCP/IP settings box and enter the appropriate values. Otherwise, resist temptation and leave this option unchecked. TCP/IP setup can get very involved, and configuration can eat up tons of time.
At long last, you're ready to connect. Double-click on the connection you defined in the Dial-Up Networking System folder, or try to access a previously defined network resource from an application such as Explorer. In either case, Win95 will initiate the dial-up procedure, and you'll be connected. Sometimes, you may not want Win95 to prompt you to make a dial-up connection; you just want it to connect so you can get your work done. You can enable or disable the dial-up networking prompt for each connection type by highlighting the connection in the Dial-Up Networking folder and selecting Connections/Settings. The dialog box that pops up lets you specify the level of prompting.
A system administrator or an IS or IT manager usually sets up and configures a Dial-Up Server at your office. And you should leave it at that, unless you're one of the above. Although it would take several columns to cover each platform you can use to host a Win95 dial-up client, let's take a look at setting up Win95 as a dial-up server.
Creating a Win95 dial-up server is a three-step process. If you follow the steps below and can't find the same menu items, pick up the Microsoft Plus for Windows 95 software kit. This treasure trove of fancy animated icons and images includes the components necessary to operate the dial-up server.
A few things before you start: If you need to host multiple sessions simultaneously, look for a different connectivity solution--the Win95 version of the dial-up server can service only one remote connection at a time. Before you start creating the dial-up server, enable File and Printer Sharing services. You may also want to incorporate password security.
Now you're ready. Select Dial-Up Server from the Connections menu in the Dial-Up Networking folder. Select Allow Caller Access from the dialog box. Finally, click on the Server Type button. Microsoft recommends you leave the Default value enabled. This starts you off in PPP mode and automatically switches to RAS if necessary. Click on OK, and the dial-up server is ready to answer calls.
So there you have it: the basics of connecting to the office from anywhere--even Block Island. In a future column, I'll investigate TCP/IP in depth, along with various connectivity options to other types of networks.
Eric Carr is owner of F1, a Mountain View, Calif.-based consultancy. To find his E-Mail ID Click Here
BY: Eric Carr
Select the Add/Remove applet in Control Panel and click on the Windows Setup tab. In Components, click on Communications and select Details.
Place a check in Dial-Up Networking.
BY: Eric Carr
To what type Once connected, what then you can use
of host are you LAN protocols will you use this WAN protocol
connecting? to access network resources? to connect
Unix host
running SLIP TCP/IP SLIP
NetWare Connect IPX/SPX NetWare Connect
NetWare via
Windows 95 IPX/SPX PPP
LanRover
or IPX/SPX, TCP/IP, PPP
NetModem/E NetBEUI
NT, Windows 95 IPX/SPX, TCP/IP, PPP
NetBEUI
NT, Windows 95, NetBEUI RAS
WFWG,
LAN Manager
BY: Eric Carr
You'll find the Make New Connection icon in the Dial-Up Networking System folder in My Computer.
To ensure you're connecting to the right type of host, right-click on the Make New Connection icon and click on the Server Type button to bring up the connection's properties. PPP: Windows 95, Windows NT 3.5, Internet is the default entry.
BY: Eric Carr
Installed a connection and can't find the SLIP protocol? That's because by default, Win95 sets up the PPP, NetWare Connect and RAS protocols, but not SLIP. SLIP support is available only on the Win95 CD-ROM or from the Windows 95 Resource Kit. If you have either of these, you can install SLIP support via the Add/Remove Programs applet. Once SLIP support is invoked, select the Windows Setup tab and click on the Have Disk button. In the Install from Disk dialog box, enter the path to the .INF file Win95 uses to install SLIP support. On the CD, the path is: admin\apptools\slip\ rnaplus.inf.
BY: Karen Kenworthy
Click Here to see a
106KB bitmap image of artwork
which goes with this article, entitled:
See DOS2WIN in Action
Click Here to see a
5.6KB bitmap image of artwork
which goes with this article, entitled:
Special Sequences for Special Keystrokes
Click Here to see a
2.48KB bitmap image of artwork
which goes with this article, entitled:
Get Fancy
Click Here to see a
6.07KB bitmap image of artwork
which goes with this article, entitled:
At Your Command
NOT LONG AGO, DOS ruled the world --and your PC. When your computer awoke, DOS took charge. Almost nothing happened without DOS. Even Windows was just a fancy DOS program.
But Windows 95 has turned the world upside down. Now, Windows takes control of your PC after it boots and doesn't let go. DOS is available, but it's just another Windows program.
You might think this status change sounds the death knell for DOS. But Windows 95's designers didn't forget their old friend. Instead of letting DOS decay, they spruced it up with some nifty new features. And they've made it possible for DOS and Windows applications to work more closely together than ever before. This month I'll push the DOS-Windows cooperation envelope.
One of the most powerful enhancements in DOS is the new START command. Found in both Windows 95 and Windows NT, it allows DOS programs and batch files to launch Windows programs. For instance, if you run this DOS command inside a Windows DOS box, you'll launch Windows' Notepad program: START NOTEPAD.EXE
The Windows program runs alongside the DOS box, so you can enter a new DOS command immediately, while the Windows program is still running.
Although the START command makes several things possible, there's a missing link. The START command can only launch a Windows program. The rest is up to you. You must type the text, make menu selections and do all the other dirty work of running a program.
Until now. I've written a small program, DOS2Win (D2W), that allows DOS programs and batch files to send keystrokes to running Windows programs. Combined with DOS' new START command, this allows you to perform most Windows functions by remote control.
Here's how a DOS batch file can control Windows' Notepad. First, the batch file launches NOTEPAD.EXE, using the new START command. It then uses START again, this time to run DOS2Win. The name of a special file that contains keystrokes to be sent to Notepad is passed to DOS2Win in its command line. If the keystroke file is named DEMO.D2W, the batch file might look like this:
START NOTEPAD.EXE START DOS2WIN.EXE DEMO.D2W
DOS2Win reads the keystroke file and sends those keystrokes directly to the Windows program started earlier.
DOS2Win's keystroke files are ordinary text files. Give them any name you like, but the default filename extension is .D2W. Normally, each line of the file starts with the text string Keys= followed by characters representing keystrokes. You can place one or more keystrokes on each line. For instance, a keystroke file might contain the following line:
Keys=ABCDEFG12345+=!@
This sends the keystrokes corresponding to the first seven capital letters of the alphabet, the digits 1 through 5, then four special symbols.
Storing keystrokes in a D2W file is usually simple. To enter letters, digits or other symbols, just type them using your favorite text editor. But storing special keystrokes, such as Enter, F4 and Down Arrow, is a bit trickier. That's because these keys don't leave a mark. Instead, when you press them, something happens.
That's why DOS-2Win allows you to specify keystrokes using special text strings, or codes. Special Sequences For Special Keystrokes shows the complete list of keystroke codes that DOS-2Win understands. With one exception--Print Scrn--the list includes all standard PC-keyboard "action" keys. You'll even find a few seldom-seen keys, such as F16. You can see a few of these special keystroke codes in action, in the D2W file shown in See DOS2Win in Action."
If you want to get even fancier, use DOS2Win to send keystroke combinations that include Shift, Ctrl and Alt.
Just place one or more of the prefixes shown in Get Fancy in front of any keystroke or code. For instance, to send the keystroke combination Alt+X, enter %X in your Keys= command. Create more elaborate keystroke combinations by specifying more than one prefix and by placing two or more normal characters inside parentheses. For instance, to send the keystroke combination Ctrl+Alt+A+B+C, use a Keys= command containing ^%(ABC).
All this fancy footwork enables you to create D2W files that send normal keystrokes (A-Z, 0-9 and other printing characters), special keystrokes (F1, Tab and so on) and keystroke combinations (Shift+Tab and so on). But in doing so, you give special meaning to a few characters, namely +, ^, %, { and }. Don't worry. DOS2Win can send those keystrokes, too. If you need to send any of these characters to a Windows program, just place them inside braces. For instance, to send a ^ key, place {^} in your Keys= command.
Most lines in D2W files start with Keys= commands, which indicate the line contains keystrokes. But D2W files can contain three other types of lines. Lines beginning with Activate= let you control which Windows program receives your keystrokes. In Windows parlance, the Activate= command changes the "input focus" from one program to another. Once activated, a program receives all keystrokes until another program is activated or receives the input focus. Any new programs you start are activated automatically.
To do its job, all the Activate= command needs is a program's titlebar text. This means you can activate only programs that are already running, perhaps as the result of an earlier START command. For instance, to activate a copy of WordPad that has opened a file named Demo.DOC, place this line in a D2W file:
Activate=Demo - WordPad
The Pause= command, shown in line 1 at the top of See DOS2Win in Action."," causes DOS2Win to pause for a specified number of seconds. This allows time for your Windows program to process one group of keystrokes before another arrives. You can also use it to give a program time to finish loading before keystrokes begin arriving.
Finally, DOS2Win provides a Start= command. Like DOS' START command, it allows you to launch a Windows program. A Start= command that launches Windows' Notepad program would look like this: Start=NOTEPAD.EXE.(The table "At Your Command" briefly describes all four DOS2Win commands.)
Now that you've seen all DOS2Win's commands, let's look at the complete D2W file shown in "See DOS2Win in Action." It assumes Windows 95's WordPad program (WRITE.EXE) has just been launched.
The first file line, Pause=5, allows WordPad to finish loading before keystrokes begin arriving. The next three lines send two text lines--each followed by the Enter key--to WordPad. Line 5, Keys=%FA, sends the keystroke combination Alt+F, followed by the single keystroke A. This causes WordPad's File menu to appear and selects Save As from that menu. Finally, Line 6 sends the name of the file where the text will be saved (DOS 2 Win Demo), followed by an Enter key.
Controlling Windows applications from DOS isn't without problems. The information flow and control is mostly one way. DOS2Win allows DOS programs and batch files to affect Windows apps, but there's no way for information about Windows and Windows programs to flow back into DOS.
This can lead to some interesting situations. For instance, a D2W file that worked perfectly one time may fail another. Consider the file shown in See DOS2Win in Action."." As we've seen, it sends a small amount of text to Windows' WordPad. It then tells WordPad to save the text in a file named "DOS 2 Win Demo" in WordPad's default file format (Word 6.0).
The first time DOS2Win processes this file, everything should work perfectly. But if it processes the file again it will fail.
This is because when the second run begins, the file "DOS 2 Win Demo" already exists. The second attempt to save this file will cause the familiar "File Exists. Overwrite?" dialog to appear. You need an extra keystroke.
There are two solutions. You can ensure that initial conditions are always the same each time you use a D2W file. For instance, the DOS program or batch file that uses the file shown in our example could remove any existing "DOS 2 Win Demo" file before starting DOS2Win.
Or you could use different D2W files, one for each possible situation. Create one D2W file for cases when "DOS 2 Win Demo" already exists (it would contain your response to the "Overwrite?" dialog), and another when "DOS 2 Win Demo" doesn't exist. If a DOS batch file is calling the shots, you can use DOS' "IF" command to pick the appropriate D2W file. If you're writing your own DOS program, use whatever conditional and branching facilities your programming language provides.
DOS2Win and its associated files are available on this CD-ROM in the directory D:\DIST\WM\WMFILES\9511OCT\POWER. If you come up with an interesting application or would like to suggest ways to improve the program, drop me a note.
Karen Kenworthy is the author of Visual Basic for Applications, Revealed! (Prima Publishing, 1994) and the manager of WINDOWS Magazine's forums on America Online and CompuServe. To find her E-Mail ID Click Here
Click Here to see a
106KB bitmap image of artwork
which goes with this article, entitled:
See DOS2WIN in Action
BY: Karen Kenworthy
Pause=5
Keys=Now is the time for all good men to
Keys=come to the aid of the party.{Enter}
Keys=The Quick Brown Fox Jumped Over The Lazy Dog.{Enter}
Keys=%FA
Keys=DOS 2 Win Demo{Enter}
BY: Karen Kenworthy
Keystroke/Code
Backspace {BACKSPACE},{BS}, or {BKSP}
Break {BREAK}
Caps Lock {CAPSLOCK}
Del {DELETE} or {DEL}
Down Arrow {DOWN}
End {END}
Enter {ENTER} or ~
Esc {ESC}
Help {HELP}
Home {HOME}
Ins {INSERT}
Left Arrow {LEFT}
Num Lock {NUMLOCK}
Page Down {PGDN}
Page Up {PGUP}
Right Arrow {RIGHT}
Scroll Lock {SCROLLLOCK}
Tab {TAB}
Up Arrow {UP}
F1 {F1}
F2 {F2}
F3 {F3}
F4 {F4}
F5 {F5}
F6 {F6}
F7 {F7}
F8 {F8}
F9 {F9}
F10 {F10}
F11 {F11}
F12 {F12}
F13 {F13}
F14 {F14}
F15 {F15}
F16 {F16}
BY: Karen Kenworthy
Key/Prefix
Shift +
Ctrl ^
Alt %
BY: Karen Kenworthy
Command Parameter Meaning
Keys Keystrokes Send keystrokes to
application that has input
focus
Activate Text in running Switch input focus to
application's titlebar particular running program
Start Name of .EXE file
to run Start a new program
Pause Seconds Pause DOS2Win for specified
number of seconds
| Back to Nov 95 How-To Columns | Up to Table of Contents | Ahead to Nov 95 Windows Online |